System and method for holistic application development and deployment in a distributed heterogeneous computing environment

ABSTRACT

Exemplary embodiments of the invention can include a method for identifying an individual component from among a plurality of components in a target system as an identified component of a plurality of identified components, mapping each one of the identified components to respective ones of a target hardware node, generating intermediate code for each respective one of the target hardware nodes, generating serialization code for each respective communication interface between the target hardware nodes, transmitting the respective intermediate codes to each one of the target hardware nodes, and transmitting respective serialization codes to each communication interface of the target hardware nodes.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/721,913, filed Dec. 19, 2019, which claims priority to U.S.Provisional Patent Application Ser. No. 62/782,009, filed Dec. 19, 2018entitled “SYSTEM AND METHOD FOR HOLISTIC APPLICATION DEVELOPMENT ANDDEPLOYMENT IN A DISTRIBUTED HETEROGENEOUS COMPUTING ENVIRONMENT.” Theentire content of these applications are incorporated herein byreference.

BACKGROUND Discussion of the State of the Art

Current software development techniques and frameworks are inadequatefor introducing, updating, or deploying applications and/or devices inan enterprise-wide network of computing devices comprising of low-levelembedded devices, fog layer of medium-powered hubs, and computationallysophisticated cloud-based servers. The difficulty in developing,designing, or deploying applications in these types of networks stemsfrom the fact that the various devices in these networks tend to bediverse and often have very different computing resources available tothem. Moreover, because of the very nature of these networks, it isoften difficult to introduce updates at one or more nodes in the networkwithout substantially altering or affecting other network components.Finally, the physical nature of low-level embedded device or edgeinternet-of-things (IoT) devices makes it difficult to fix, patch,and/or update these devices.

For example, embedded devices or edge IoT devices in such networks maybe shipped with software that is written on bare metal, or with limitedoperating system and networking capabilities. Thus, once such devicesroll off the assembly line, the only way to fix, patch, and/or updatethe device is through a technician visit or a recall. Moreover,development teams are often forced to work inefficiently to solveproblems in heterogenous IoT networks because the various devices inthese networks tend to be diverse, both in terms of their capabilities,and also in terms of their internal logic and communications protocols.For example, in distributed heterogeneous designs, large amounts ofdevelopment effort are spent simply getting all the differentcomponents—and the teams developing the components—communicating witheach other. The embedded part of the project team often spends most ofits time simply getting the software to come up on the hardware withinresource constraints and without crashing, while the cloud developersare adding and deploying new features on a weekly basis. This problem isexacerbated because in cloud-targeted application development, resourcesand frameworks have become and are continuing to become even moreabstract. Bare metal machines have given way to virtual machines, which,in turn, have given way to containers. As a result, software componentsare built to communicate via lightweight APIs and message-buses thateliminate developer considerations of where or how many of a componentis deployed. As a result, the inefficiencies introduced withindevelopment teams in terms of capital and human resources is made evenworse.

Additionally, testing a newly developed application is an incrediblydifficult process because it is often difficult to determine the devicesand/or the code that is present at any given part of the network. As aresult, these new developments are tested—often for the first time—in afully deployed operational environment. This practice can potentiallycause significant damage and down-time to the environment, andpotentially introduce the system to security vulnerabilities. As aresult, the process of deploying new embedded applications and/ordevices often tends to be harrowing experience.

SUMMARY

The present invention overcomes many of the technical difficultiesoutlined above by offering a development environment, and runtime systemthat considers the heterogeneous targets of an IoT product as a single,coherent whole. More specifically, the present invention consumes anapplication specification that is associated with one or more devices orapplications in a network environment, identifies independent componentsin the network by identifying message-passing boundaries and/ordata-dependencies between code paths, maps the consumed applicationspecification to identified independent components by leveraging one ormore libraries (at least one of a generic library, anarchitecture-optimized library, or a part-specific library), encodes onemore objects of the consumed application specification for a target'scommunication channel by detecting at least one of: message types thatmay traverse each channel from one target node to another, and thesecurity needs for the communication channel, and transforms theconsumed application specification into a format suitable for a targetnode.

Specifically, a method for the following is disclosed: identifying, by aprocessing system comprising a processor, an individual component fromamong a plurality of components in a target system as an identifiedcomponent of a plurality of identified components; mapping, by theprocessing system, each one of the identified components to respectiveones of a target hardware node; generating, by the processing system,intermediate code for each respective one of the target hardware nodes;generating, by the processing system, serialization code for eachrespective communication interface between the target hardware nodes;transmitting, by the processing system, the respective intermediatecodes to each one of the target hardware nodes; and transmitting, by theprocessing system, respective serialization codes to each communicationinterface of the target hardware nodes.

A computer program product comprising a non-transitory computer readablestorage medium having instructions encoded thereon that, when executedby a processor, cause the processor to: consume an applicationspecification associated with a plurality of devices provided in anetwork environment as a consumed application specification; identifyindependent components in the network by identifying message-passingboundaries between code paths as identified independent components; mapthe consumed application specification to the identified independentcomponents by leveraging one or more code libraries; encode one moreobjects of the consumed application specification for a targetcommunication channel by detecting message types that may traverse eachchannel from one target node to another; and transform the consumedapplication specification into a format suitable for a target node.

A system comprising: a processing system including a processor; and amemory, coupled to the processing system, that stores executableinstructions and that, when executed by the processing system,facilitate performance of operations, comprising: identifying anindividual component from among a plurality of components in a targetsystem as an identified component of a plurality of identifiedcomponents; mapping each one of the identified components to respectiveones of a target hardware node; generating serialization code for eachrespective communication interface between the target hardware nodes;and transmitting, by the processing system, respective serializationcodes to each communication interface of the target hardware nodes.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

The accompanying drawings illustrate several embodiments and, togetherwith the description, serve to explain the principles of the inventionaccording to the embodiments. It will be appreciated by one skilled inthe art that the particular arrangements illustrated in the drawings aremerely exemplary and are not to be considered as limiting of the scopeof the invention or the claims herein in any way.

FIG. 1 is a block diagram illustrating an exemplary operatingenvironment, according to a preferred embodiment of the invention.

FIG. 2 is a block diagram illustrating an exemplary applicationdeployment system, according to a preferred embodiment of the invention.

FIG. 3 is a flow diagram illustrating an example method, according to apreferred embodiment of the invention.

FIG. 4 is an exemplary illustration of the present invention in adeployment configuration.

FIG. 5 is an exemplary illustration of the present invention in adeployment configuration.

FIG. 6 is an exemplary illustration of the present invention employing acode library.

FIG. 7 is an exemplary illustration of the present invention applying aserialization/de serialization strategy.

FIG. 8 is an exemplary illustration of the present invention deployingcode to downstream elements of a system in accordance with the method ofFIG. 3.

FIG. 9 is an exemplary illustration of the present invention deployingcode to downstream elements of a system in accordance with the method ofFIG. 3 and system of FIG. 8.

FIG. 10 is an exemplary illustration of the present invention deployingcode to downstream elements of a system in accordance with the method ofFIG. 3 and system of FIG. 8.

FIG. 11 illustrates one embodiment of components of an example machineable to read instructions from a machine-readable medium and executethem in a processor (or controller).

FIG. 12 illustrates on embodiment of the computing architecture thatsupports an embodiment of the inventive disclosure.

FIG. 13 illustrates components of a system architecture that supports anembodiment of the inventive disclosure.

FIG. 14 illustrates components of a computing device that supports anembodiment of the inventive disclosure.

DETAILED DESCRIPTION

The inventor has conceived, and reduced to practice, a system and methodfor writing and deploying applications to a distributed networkcomprising of heterogenous devices.

One or more different embodiments may be described in the presentapplication. Further, for one or more of the embodiments describedherein, numerous alternative arrangements may be described; it should beappreciated that these are presented for illustrative purposes only andare not limiting of the embodiments contained herein or the claimspresented herein in any way. One or more of the arrangements may bewidely applicable to numerous embodiments, as may be readily apparentfrom the disclosure. In general, arrangements are described insufficient detail to enable those skilled in the art to practice one ormore of the embodiments, and it should be appreciated that otherarrangements may be utilized and that structural, logical, software,electrical and other changes may be made without departing from thescope of the embodiments. Particular features of one or more of theembodiments described herein may be described with reference to one ormore particular embodiments or figures that form a part of the presentdisclosure, and in which are shown, by way of illustration, specificarrangements of one or more of the aspects. It should be appreciated,however, that such features are not limited to usage in the one or moreparticular embodiments or figures with reference to which they aredescribed. The present disclosure is neither a literal description ofall arrangements of one or more of the embodiments nor a listing offeatures of one or more of the embodiments that must be present in allarrangements.

One embodiment of the subject disclosure includes method that performsidentifying an individual component from among a plurality of componentsin a target system as an identified component of a plurality ofidentified components, mapping each one of the identified components torespective ones of a target hardware node, generating intermediate codefor each respective one of the target hardware nodes, generatingserialization code for each respective communication interface betweenthe target hardware nodes, transmitting the respective intermediatecodes to each one of the target hardware nodes, and transmittingrespective serialization codes to each communication interface of thetarget hardware nodes.

Another embodiment of the subject disclosure includes a device having amemory that stores executable instructions and a processor coupled tothe memory. The processor, responsive to executing the executableinstructions, performs operations including consuming an applicationspecification associated with a plurality of devices provided in anetwork environment as a consumed application specification, identifyingindependent components in the network by identifying message-passingboundaries between code paths as identified independent components,mapping the consumed application specification to the identifiedindependent components by leveraging one or more code libraries,encoding one more objects of the consumed application specification fora target communication channel by detecting message types that maytraverse each channel from one target node to another, and transformingthe consumed application specification into a format suitable for atarget node.

Headings of sections provided in this patent application and the titleof this patent application are for convenience only and are not to betaken as limiting the disclosure in any way.

Devices that are in communication with each other need not be incontinuous communication with each other, unless expressly specifiedotherwise. In addition, devices that are in communication with eachother may communicate directly or indirectly through one or morecommunication means or intermediaries, logical or physical.

A description of an aspect with several components in communication witheach other does not imply that all such components are required. To thecontrary, a variety of optional components may be described toillustrate a wide variety of possible embodiments and in order to morefully illustrate one or more embodiments. Similarly, although processsteps, method steps, algorithms or the like may be described in asequential order, such processes, methods and algorithms may generallybe configured to work in alternate orders, unless specifically stated tothe contrary. In other words, any sequence or order of steps that may bedescribed in this patent application does not, in and of itself,indicate a requirement that the steps be performed in that order. Thesteps of described processes may be performed in any order practical.Further, some steps may be performed simultaneously despite beingdescribed or implied as occurring non-simultaneously (e.g., because onestep is described after the other step). Moreover, the illustration of aprocess by its depiction in a drawing does not imply that theillustrated process is exclusive of other variations and modificationsthereto, does not imply that the illustrated process or any of its stepsare necessary to one or more of the embodiments, and does not imply thatthe illustrated process is preferred. Also, steps are generallydescribed once per aspect, but this does not mean they must occur once,or that they may only occur once each time a process, method, oralgorithm is carried out or executed. Some steps may be omitted in someembodiments or some occurrences, or some steps may be executed more thanonce in a given aspect or occurrence.

When a single device or article is described herein, it will be readilyapparent that more than one device or article may be used in place of asingle device or article. Similarly, where more than one device orarticle is described herein, it will be readily apparent that a singledevice or article may be used in place of the more than one device orarticle.

The functionality or the features of a device may be alternativelyembodied by one or more other devices that are not explicitly describedas having such functionality or features. Thus, other embodiments neednot include the device itself.

Techniques and mechanisms described or referenced herein will sometimesbe described in singular form for clarity. However, it should beappreciated that particular embodiments may include multiple iterationsof a technique or multiple instantiations of a mechanism unless notedotherwise. Process descriptions or blocks in figures should beunderstood as representing modules, segments, or portions of code whichinclude one or more executable instructions for implementing specificlogical functions or steps in the process. Alternate implementations areincluded within the scope of various embodiments in which, for example,functions may be executed out of order from that shown or discussed,including substantially concurrently or in reverse order, depending onthe functionality involved, as would be understood by those havingordinary skill in the art.

Conceptual Architecture

FIG. 1 illustrates an exemplary network comprising heterogeneousdevices, which, in accordance with an embodiment of the invention, iscomprised of one or more sensor device(s) 102, one or more gatewaydevices 104, servers 106, network 110, and an application deploymentsystem 108. Although not illustrated in FIG. 1, the network may also becomprised of user devices or mobile computing devices that interfacewith the server or portions of the network. The network can exemplary beapplied across an enterprise-wide network controlling any number ofdownstream devices. The specific elements described and illustratedherein may be varied in accordance with this description, as would beapparent to a person of ordinary skill in the art, without departingfrom the scope of the invention.

The sensor devices 102 that may be deployed in the network environmentmay vary based on the one or more uses cases described below. Butgenerally, the sensor devices 102 capture certain information andprovide to the gateway devices 104 either directly or via the network110. In an IoT framework, the sensor devices 102 may be comprised ofsensors (temperature sensors, imaging devices, machine vision, opticallight sensors, position/proximity/presence sensors,motion/velocity/displacement sensors, humidity/moisture sensors,acoustic/sound/vibration detection sensors, chemical and gas sensors,flow rate detection sensors, force/load/torque/strain/pressure sensors,leak/level detectors, electric/magnetic sensors, acceleration/tiltsensors, etc.), actuators, recording devices, and more, as would beapparent to a person of ordinary skill in the art. In some instances,the software on the sensor devices 102 may exist in an abstractionlayer. But in other instances, the code may be stored on metal. In someembodiments, the sensor devices 102 may be integrated into computingdevices that interface with the device.

The gateway devices 104 that may be deployed in a heterogeneous networkenvironment may vary based on one or more use cases described below. Butgenerally, the gateway devices 104 interface with sensor devices 102 tocompile, store, record, organize, the data that is output by the sensordevices 102. In an IoT framework, the gateway devices interface with thesensor devices 102 to record and/or store the values output by thesensor devices 102. In some embodiments, the gateway devices 104 may becomprised of their own IoT protocols, data management and messagingprotocols, etc., as would be apparent to a person of ordinary skill inthe art.

The servers 106 that may be deployed in a heterogenous networkenvironment may vary based on one or more use cases described below. Butgenerally, the server 106 interface with the gateway devices to enablecertain applications, manage devices, manage data, etc., as would beapparent to a person of ordinary skill in the art. The various devicesthat may be used are described in greater detail below in reference toFIGS. 9-12.

The application deployment system 108 interfaces with the entire networkto generate code that can be deployed at the sensor devices 102, gatewaydevices 104, and the servers 106. More specifically, the applicationdeployment system 108 analyzes the network environment, splits it amongone or more configured targets including a sensor level target, agateway level target, and a server level target. In addition, theapplication deployment system 108 generates serialization code that issynthesized for each intra-node message-passing boundary. For example,in one embodiment of the invention, the application deployment system108 generates intermediate code that is built by native compilers andtransactionally deployed to physical nodes. As such, the applicationdeployment system 108 enables deployment at build time, which is asignificant breakthrough over the traditional systems for deployingdevices or applications in a network of heterogenous devices. Thespecific components of the application deployment system 108 aredescribed in greater detail below in reference to FIG. 2.)

The sensor devices 102, the gateway devices 104, the servers 106, andthe application deployment system 108 may be connected via a network110. The network 110 may comprise a wide area network (WAN). The network110 may comprise a local area network (LAN). The network 110 maycomprise a physical connection between two or more of the scoring system102, the feedback device 104, and the digital data acquisition system106. The network 110 may comprise a bus between two or more of thescoring system 102, the feedback device 104, and the digital dataacquisition system 106. At least a portion of the network 110 may beprivate. At least a portion of the network 110 may be public, such asthe Internet. The network 110 may be capable of transporting messagescomprising one or more messaging protocol. Network cloud 150 generallyrepresents a network or collection of networks (such as the Internet ora corporate intranet, or a combination of both) over which the variouscomponents illustrated in FIG. 1 (including other components that may benecessary to execute the system described herein, as would be readilyunderstood to a person of ordinary skill in the art). In particularembodiments, network 110 is an intranet, an extranet, a virtual privatenetwork (VPN), a local area network (LAN), a wireless LAN (WLAN), a widearea network (WAN), a metropolitan area network (MAN), a portion of theInternet, or another network 110 or a combination of two or more suchnetworks 150. One or more links connect the systems and databasesdescribed herein to the network 110. In particular embodiments, one ormore links each includes one or more wired, wireless, or optical links.In particular embodiments, one or more links each includes an intranet,an extranet, a VPN, a LAN, a WLAN, a WAN, a MAN, a portion of theInternet, or another link or a combination of two or more such links.The present disclosure contemplates any suitable network 110, and anysuitable link for connecting the various systems and databases describedherein.

The network 110 connects the various systems and computing devicesdescribed or referenced herein. In particular embodiments, network 110is an intranet, an extranet, a virtual private network (VPN), a localarea network (LAN), a wireless LAN (WLAN), a wide area network (WAN), ametropolitan area network (MAN), a portion of the Internet, or anothernetwork or a combination of two or more such networks. The presentdisclosure contemplates any suitable network 110.

One or more links couple one or more systems, engines or devices to thenetwork 110. In particular embodiments, one or more links each includesone or more wired, wireless, or optical links. In particularembodiments, one or more links each includes an intranet, an extranet, aVPN, a LAN, a WLAN, a WAN, a MAN, a portion of the Internet, or anotherlink or a combination of two or more such links. The present disclosurecontemplates any suitable links coupling one or more systems, engines ordevices to the network 110.

In particular embodiments, each system or engine may be a unitary serveror may be a distributed server spanning multiple computers or multipledatacenters. Systems, engines, or modules may be of various types, suchas, for example and without limitation, web server, news server, mailserver, message server, advertising server, file server, applicationserver, exchange server, database server, or proxy server. In particularembodiments, each system, engine or module may include hardware,software, or embedded logic components or a combination of two or moresuch components for carrying out the appropriate functionalitiesimplemented or supported by their respective servers. For example, a webserver is generally capable of hosting websites containing web pages orparticular elements of web pages. More specifically, a web server mayhost HTML files or other file types, or may dynamically create orconstitute files upon a request, and communicate them to clients devicesor other devices in response to HTTP or other requests from clientsdevices or other devices. A mail server is generally capable ofproviding electronic mail services to various clients devices or otherdevices. A database server is generally capable of providing aninterface for managing data stored in one or more data stores.

In particular embodiments, one or more data storages may becommunicatively linked to one or more servers via one or more links. Inparticular embodiments, data storages may be used to store various typesof information. In particular embodiments, the information stored indata storages may be organized according to specific data structures. Inparticular embodiment, each data storage may be a relational database.Particular embodiments may provide interfaces that enable servers orclients to manage, e.g., retrieve, modify, add, or delete, theinformation stored in data storage.

The system may also contain other subsystems and databases, which arenot illustrated in FIG. 1, but would be readily apparent to a person ofordinary skill in the art. For example, the system may include databasesfor storing data, storing features, storing outcomes (training sets),and storing models. Other databases and systems may be added orsubtracted, as would be readily understood by a person of ordinary skillin the art, without departing from the scope of the invention.

Detailed Description of Exemplary Embodiments

FIG. 2 illustrates an exemplary embodiment of the application deploymentsystem 108 of FIG. 1. In one exemplary embodiment, the applicationdeployment system 108 is comprised of a consumption engine 201,splitting engine 202, target assignment engine 204, targetspecialization engine 206, a serializer generation engine 214, and atransformation engine 218. As would be readily apparent to a person ofordinary skill in the art, the various modules or engines may becomprised of other sub-modules or engines and may be arranged ordeployed in a variety of different engines and configuration inaccordance with the description herein without departing from the scopeof the present invention.

The consumption engine 201 exemplarily consumes an applicationspecification associated with one or more devices or application in anetwork environment. In a general sense, an application specificationmay be a task/program/algorithm here that may result in an applicationor an instance of a device. The application specification may becomprised of security layers, relevant libraries, communicationchannels, and other information that may be crafted or instantiated aspart of the compilation process. In one embodiment of the invention, theapplication specification may be source code, script based, GUI based,etc.

The splitting engine 202 exemplarily analyzes the network to identifyindependent components in the network. In one exemplary embodiment, thecomponent splitting engine 202 identifies independent components byidentifying message-passing boundaries and data dependencies betweencode paths. In one exemplary embodiment, an independent component isidentified as such if it does not share a data dependency with anothercomponent.

The target assignment engine 204 exemplarily maps independent componentsto independent target hardware nodes. A variety of differentmethodologies may be used to map independent components to independenttarget hardware nodes. For example, the independent components may bemapped to hardware nodes based on an explicit configuration in thedeployed network. For example, a user may define a set of configurationinformation that details the available network resources upon which theapplication is to be deployed. This may include a given fixed networkedcompute node, a networked system of homogeneous compute nodes, or aheterogeneous fixed network of compute nodes. In another example, theindependent components may be mapped based on dependency on a specifictarget peripheral, such as dependence on specific compute or networkresources, i.e., network bandwidth, certain hardware acceleration, etc.In another exemplary embodiment, the independent components may bemapped by performing various cost analysis functions. For example, thecomponent target assignment engine 204 may identify available networkedcomputer resources and partition the application according to a givencost criteria, such as compute performance, power consumption, bandwidthrequirements, etc. Networks upon which a given target application isdeployed may be fixed in terms of network architecture, may be fluid interms of self-organizing networks, or may be varied in terms ofnetworked swarm intelligence such as rapidly evolving systems of dronelike devices.

The target specialization engine 206 exemplarily leverages the genericlibrary 208, the architecture-optimized library 210, and/or apart-specific library 212 to generate code that is specialized for eachtarget hardware node and/or independent component. Generally, the threelibraries mentioned above, the generic library 208, thearchitecture-optimized library 210, and part-specific library 212,include one or more implementations that may be deployed at specificcomponents in the network and at specific target hardware nodes. Forexample, the generic library 208 includes implementation code that isless specific. The part-specific library, on the other hand, includescode that is more specific. The target specialization engine 206exemplarily selects one or more appropriate libraries for each targethardware node and selects an implementation code that is appropriate fora deployment. As such, the target specialization engine 206 exemplarilyresolves proxy classes and objects against the most target-architectureand peripheral-specific implementation that may be available to it.

The serializer generation engine 214 exemplarily generates serializationand/or de-serialization code for each target's communication channel.Serialization/deserialization, as used herein, broadly refers toencoding something to go over a communication wired, wireless, or otherconnection. The disclosure herein is not limited to serialization as inforcing of packet orderings, and is not meant to refer to internalmemory references or any specific internal memory formats. In oneembodiment, the serializer generation engine 214 is comprised of amessage type detection engine 216, and a serialization strategygeneration engine 218. The message type detection engine 216 detects themessage types that may traverse each channel from one target hardwarenode to another. The serialization strategy generation engine 218identifies the security needs for the communication channel, channelconfiguration of one or more target hardware node. The serializergeneration engine 214 uses the information provided by the message typedetection engine 216 and the serialization strategy generation engine218 to generate serialization/deserialization code for each target'scommunication channel.

The transformation engine 220 exemplarily transforms the consumedapplication specification into a format suitable for a target node. Thesuitable format may be determined based on analysis performed by variouscomponents of the application deployment system 108 described above andthroughout the specification. In one embodiment, the transformationengine 220 may compile in a binary executable. However, more generally,the transformation engine 220 may generate an intermediaterepresentation that is target agnostic, or other representation such asscript language or other. Moreover, there may not be an explicitapplication code; the transformation engine 220 may generate securitymodules that may be deployed to the devices as part of a security layeron top of which the application code sits for a given networked node. Inone embodiment, the transformation engine 220 may not generateexecutable code at all; rather a new configuration file may be pushedout to update access ports, or other non-executable code parts of thenode.

The implementation described herein may be employed in a variety of usecases. For example, the present invention may be used to implementproceduralized security implementation. In order to do so, theapplication deployment system 108 may be used to update software atvarious target nodes, and enable communication via serialization, keyhandling, encryption and transport. This enables a more secure methodfor updating code or introducing new hardware in a heterogeneous networkenvironment. In one embodiment, for example, the implementation of thepresent invention enables automatic, secure distribution ofcryptographic key material. Moreover, the implementation enablesdistribution of encrypted, signed software updates on one or moreparticipating nodes.

The implementation described herein may also be employed to enableintegrated security administration. In this implementation, theapplication deployment system 108 interfaces with a user device toauthenticate a user, and automatically and securely distributecrytopgraphic key material and encrypted, signed software updates to oneor more components, including a key management component, a firmwarerepository, and/or an app server.

In one embodiment, the present invention may also be deployed in a chiparchitecture, such as, for example, RISC-V, but other instruction setarchitectures may be used, as would be readily apparent to a person ofordinary skill in the art, without departing from the scope of theinvention. Such methods of designing chip architecture in the cloud maybe used in fog computing by, for example, plugging in the chiparchitecture, running real time network traffic on it, and iterativelyenabling design of software in a full stack environment. In anotherexample, the chip architecture with the present invention implementationmay be used in edge computing to evaluate real application in a networksystem, and rapidly redeploy the invention at edge devices.

FIG. 3 illustrates an exemplary process 300 for deploying codeautomatically in a heterogenous network environment. The processtypically begins by identifying independent components in a heterogenoussystem, such as a system composed of, for example, the sensor device102, the gateway device 104, and server 106 exemplarily illustrated byFIG. 1. The heterogenous system can include some or all elements in anenterprise-wide network of connected devices. In one embodiment, step320 identifies message-passing boundaries and data dependencies betweencode paths in the heterogenous system. In one exemplary embodiment, anindependent component is identified as such if it does not share a datadependency with another component. For example, the independentcomponents may be mapped to hardware nodes based on an explicitconfiguration in the deployed network. For example, a user may define aset of configuration information that details the available networkresources upon which the application is to be deployed. This may includea given fixed networked compute node, a networked system of homogeneouscompute nodes, or a heterogeneous fixed network of compute nodes. Inanother example, the independent components may be mapped based ondependency on a specific target peripheral, such as dependence onspecific computer or network resource. A variety of different methods toautomatically analyze an application at message passing boundaries maybe applied. These can be either inserted into the applicationspecification and/or configuration manually by a user, or performedautomatically by build tools process. The information that transmitsover these message passing boundaries may be messages themselves ofvarying types. A number of different messages can be sent, whetherTCP/IP, or other higher level custom formats like XML/Javascript etc.Generally, message-boundary detection takes place remotely from thetarget system. The analysis for message passing boundaries is done atthe build/complete stage of the process, thus done on build servers orworkstations. The segmented application is then typically deployed tothe target system on which the application ultimately runs. The buildsystem may be a separate machine from the target system on which theapplication is deployed, but, as may be appreciated by persons ofordinary skill in the art, they may not be.

Once an independent component is identified, it is separated in step 330from other components by a message-passing boundary to exemplarilydivide the heterogenous system into discrete segments. Thereafter, theprocess continues by mapping independent components to independenttarget hardware nodes in step 340. A variety of different methodologiesmay be used to map independent components to independent target hardwarenodes, including the one noted above in reference to FIG. 2.

The process continues to step 350 by generating code that is specializedfor each target hardware node and/or discrete component to allowcommunication with a target communication node of the divided system.Exemplarily, a variety of different libraries may be used to deployappropriately generic or specific code at a variety of different targethardware nodes. As such, the process resolves proxy classes and objectsagainst the most target-architecture and peripheral-specificimplementation that may be available to it. In one exemplary embodiment,the process generates code by retrieving sample codes from a library andthen applying the identified variables making up the data communicatedthrough communication boundaries. Exemplarily, the most specific codethat can be determined is selected. The generating of specialized codecan first include searching part specific libraries as exemplarilyillustrated in step 360. If a part specific code can be found, method300 proceeds to step 380. If no part specific code is found in step 360,step 365 exemplarily searches for an architecture optimized code from anarchitecture optimized library. If such a code is found, method 300proceeds then to step 380. If no appropriate code is found in step 365,method 300 proceeds to step 370 where generalized code is retrieved froma generic library. If no code is found at step 370, then a build/linktime error may occur.

In some embodiments, each of steps 360, 365, and 370 are performed foreach discrete segment to return all available coding options.Additionally, in some embodiments, various cost analysis functions canbe applied to decide, in step 350, which code can be provided to step380. Exemplarily, in step 380, serialization and de-serialization codeis generated for each discrete component as required. In some instances,a terminal device may only need to develop a singleserialization/deserialization code for that discrete segments target'scommunication channel. In one embodiment, the process detects a messagetype that may traverse each channel from one target hardware node toanother, and/or the security needs for the communication channel,channel configuration of one or more target hardware node. Thisinformation is used to generate serialization/deserialization code foreach target's communication channel. For example, the types of data andmessage types crossing the boundaries are instantiated and applied tothat code.

Exemplarily, the code may thereafter be deployed in step 390 at a one ormore target hardware nodes in accordance with one or more embodiments ofthe invention. In some embodiments, the deployment can be applied toindividual discrete elements of the heterogenous system, entire branchesor paths of the network, or across an enterprise-level deployment. Insome embodiments, the deployment can include various security steps,including distributing keys and encryption codes, that would allow, forexample, the application deployment system 108 to distributeserialization codes, de-serialization codes, programming updates, workassignments, removal of nodes, and addition of nodes.

FIG. 4 illustrates an exemplary illustration of a heterogeneous system400. Heterogenous system 400 can perform several tasks employing severaldevices employed within the system. Exemplarily the system heterogeneoussystem 400 can include upstream and downstream connected devices, suchas the exemplary sensor system illustrated in FIG. 1. In otherembodiments, the heterogeneous system 400 can include many differentservers, gateways, and downstream devices across an enterprises-widesystem including many different devices. Thus, in one example, an oilfield that employs countless sensors and gateway devices can becontrolled and updated as desired. Exemplarily, the heterogeneous system400, in accordance with an embodiment of the invention, can be analyzedand divided into three separate instances as exemplarily illustrated insegmented system 450. Referring to method 300 illustrated in steps 310,320, and 330 within FIG. 3, the individual components of theheterogeneous system 400 are identified and divided into the discretesegments of the segmented system 450. In one embodiment, the componentswithin the heterogeneous system 400 can be identified based on locatingmessage-passing boundaries and data-dependencies within theheterogeneous system 400.

Exemplarily, components and programs within the heterogeneous system 400are analyzed, as represented by arrow 455, for message-passingboundaries and data dependencies between code paths. An independentcomponent of the heterogeneous system 400 exemplarily can be separatedfrom other components based on the identified message-passing boundary.In addition, an identified component can be determined based on its datadependency. Exemplarily, an identified component will share no datadependency with other components within the heterogeneous system 400. Inadditional embodiments, once independent components of the heterogeneoussystem 400 are identified, they can be mapped to independent targethardware nodes based on the application configuration. Exemplarily, themapping of components to these targets can be determined by an explicitconfiguration of the heterogeneous system 400 or by determining acomponent dependency based on a specific target peripheral.

In one embodiment, the heterogeneous system 400 can represent atemperature monitoring system which exemplarily measures a temperatureof an environment over time and provides a graph of that temperatureversus time. In this example, the heterogeneous system 400 can include atimer 410 which triggers a temperature sensor that provides a readtemperature value 420. The read temperature value 420 can be used toexemplarily create a rolling average value 425 which can then be storedas a stored value 430. In this embodiment, the stored value 430 can beanalyzed to exemplarily provide a graph in the Showgraph function 430.Exemplarily, the Showgraph function 430 output is served or transmittedto a user client device.

Exemplarily, in accordance with an embodiment of this invention, theheterogeneous system 400 can be analyzed, as represented by arrow 455,to determine message boundaries and individual components. Based on thisanalysis, different segments within the heterogeneous system 400 can beidentified as exemplarily illustrated in the segmented system 450.Within the segmented system 450, the identified components can include asensor 460, a gateway device 470, and a server 480. In other exemplaryembodiments, any number of target configurations and identifiedcomponents can be recognized from the heterogenous device beingconsidered. In this exemplary embodiment, the sensor 460 can include atimer function 462 and read temperature function 464. The gateway 470can include a rolling average function 472 while the server 480 canperform a storing value function 482 and a graph, such as a “Showgraph”,function 484.

FIG. 5 illustrates an exemplary illustration of the generation of codefor intra-node message-passage boundaries that were identified for thesegmented system 450 of FIG. 4. Exemplarily, FIG. 5 illustrates a buildof intermediate code that is deployed to physical nodes between theseboundaries. FIG. 5 illustrates the communication between sensor portion510, gateway 540, and server 590 that comprise the segmented system 450.Within the sensor portion 510, the similar functions of theheterogeneous system 400 from FIG. 4 are employed in the timer function512 and read temperature function 514. Next, within the sensor portion510, a protocol serializer 520 is employed to provide an output, such asa Bluetooth message, although any message interface or process may beused, BT output 530, across the node 535 identified between the sensor510 and the gateway 540. In other embodiments, different communicationmodes can be employed, from exemplary wired connections to variouswireless communication paths.

Next, the BT output 530 is received at gateway 540 and is de-serializedat de-serializer 545. Next, the rolling average function 550 isperformed within the gateway 540 and then that value is serialized inthe gateway protocol serializer 560 to create an output, such as messagevia a Message Queuing Telemetry Transport pathway, or MQ 570, althoughany message interface or process may be used. The message MQ 570 is thentransported across the node 575 between gateway 540 and server 590. Atthe server 590, the MQ message 570 is received and de-serialized at theprotocol de-serializer 580. The server 590 then uses these values at thestore average function 592 and can perform the show graph function 594.That is, referring to method 300 illustrated within FIG. 3, specializedcode is created, including a serialization and de-serialization code foreach communication channel between the target hardware nodes.Exemplarily, once individual components of a heterogenous system areidentified, the components are mapped to independent target hardwarenodes based on the application configuration. In other embodiments,different communication modes can be employed, from exemplary wiredconnections to various wireless communication paths.

Referring to method 300 of FIG. 3, where in step 390 the resulting codeis deployed, FIG. 5 exemplarily illustrates the deployment of code whereintermediate code generated in step 350 of FIG. 3 can be deployed toeach physical node such as sensor 510, gateway 540, and server 590 ofFIG. 5 to perform message serialization/deserialization by protocolserializer 520 and 560 and protocol de-serializer 545 and 580 betweeneach node of the identified nodes 535 and 575. Exemplarily, the messagetypes and data crossing each boundary is identified and incorporatedinto the message serialization/deserialization protocols. In someexamples, the BT message 530 would include the temperature datacollected by the sensor 510. In other examples, the MQ message 570includes data such as the rolling average compiled by the gateway 540.In other embodiments, the gateway 540 would collect rolling averagesfrom one or more sensors and communicate that data through message MQ570 to the server. Exemplarily, by identifying these nodes, updates tothe various identified components including adding new componentsbetween the identified components, or changing the work being performedat each component can be accomplished without modifying eachapplication's code.

As discussed above with respect to FIG. 1, the application deploymentsystem 108 can exemplarily generate code that can be deployed at thesensor 510, gateway 540, and server 590 of FIG. 5. Exemplarily, the codecan include serialization code that is synthesized for each intra-nodemessage-passing boundary between the sensor 510, gateway 540, and server590. Additionally, newly added devices can be added between pre-existingnodes by simply re-coding the identified protocol serializer 520 and 560and protocol de-serializer 545 and 580 for the existing devices so as toadapt to newly updated code, newly added devices, or changes to theoperation of intermediate devices in the heterogenous system.

FIG. 6 illustrates an exemplary example of resolving proxy classes andobjects for the identified components. Exemplarily, the resulting code610 can be identified and generated from the various libraries includinga generic library 620, an architecture-optimized library 630, and apart-specific library 640 to result in the most target architecture andperipheral specific implementation possible. In this example, thelibraries arranged from a least specific and generic version of code inthe generic library 620 to the more specific, the architecture-optimizedlibrary 630, and to the most specific, the part-specific library 640. Inthe example presented within FIG. 6, the code for proxy class Y can befound in all three libraries, and accordingly, the most specific codefrom the part-specific library is chosen. On the other hand, the codefor proxy class X is only available in two of the three libraries, andin this instance the more specific code from the architecture-optimizedlibrary 630 is chosen.

FIG. 7 illustrates an exemplary serialization strategy that can beemployed, for example, in the generating serialization/deserializationcode step 310 of method 300 in FIG. 3. FIG. 7 illustrates aserialization strategy for generating a communication channelserialization/deserialization strategy can be based on a shared targetcommunication channel capabilities and configuration to connect thenodes between identified components. Exemplarily, by leveraging aknowledge of channel implementation and the message types that willtraverse each channel, a strategy for serialization/deserialization canbe generated. In addition, a security strategy can be considered increating the serialization/deserialization strategy.

Exemplarily, the messages that cross the channel between the exemplarytwo targeted components includes the message serialization itself, asecurity strategy as illustrated by the Key Management and/orcryptologic method employed between the targeted components.Exemplarily, the channel configuration can inform the channel managementprotocols between the targeted components which would allow for thecontrol and security of downstream components by a central device, suchas a customer controlling and updating its downstream IoT devices.

FIG. 8 provides an exemplary illustration of a system and method 800 fordeploying the various codes, including serialization andde-serialization codes as described above in step 390 of FIG. 3.Additionally, in some embodiments, additional code, such as updated codeaffecting the programming of individual components in the divided systemmay be applied to the various individual components of the dividedsystem. In other embodiments, additional target components can be addedor removed from the system as desired. Exemplarily, the applicationdeployment system 810, similar to the application deployment system 108described in FIG. 1 can control the process of deploying updated code,including serialization and de-serialization codes to the discretecomponents of the heterogenous system that was divided in step 330, forexample, in method 300 of FIG. 3.

Exemplarily, the application deployment system 810 can include variousupstream, administrative control and programming apparatus andmanagement tools. The application deployment system 810 includes thecoding and other components as exemplarily described in FIG. 2 as wellas other heterogenous system management personnel and systems thatcontrol the heterogenous system. In one embodiment, software updates 820for each, or individual, target components of the divided system can begenerated at the application deployment system 810 and applied todownstream components, such as cloud server 870, which can be similar toserver 590 of FIG. 5, server 480 of FIG. 4, and server 106 of FIG. 1.Additionally, software updates 820 for each, or individual, targetcomponents of the divided system can be generated at the applicationdeployment system 810 and applied to downstream components, such asgateway 880, similar to gateway 540 of FIG. 5, gateway 470 of FIG. 4,and gateway 104 of FIG. 1. Additionally, software updates 820 for each,or individual, target components of the divided system can be generatedat the application deployment system 810 and applied to downstreamcomponents, such as an edge device 890, which can be considered like thesensor 540 of FIG. 5, sensor 460 of FIG. 4, and sensor 102 of FIG. 1.

In one embodiment, serialization codes 830, including serialization andde-serialization codes 830, for each, or individual, target componentsof the divided system can be generated at the application deploymentsystem 810 and applied to downstream components, such as cloud server870, like server 590 of FIG. 5, server 480 of FIG. 4, and server 106 ofFIG. 1. Additionally, serialization codes 830 for each, or individual,target components of the divided system can be generated at theapplication deployment system 810 and applied to downstream components,such as gateway 880, similar to gateway 540 of FIG. 5, gateway 470 ofFIG. 4, and gateway 104 of FIG. 1. Additionally, serialization codes 830for each, or individual, target components of the divided system can begenerated at the application deployment system 810 and applied todownstream components, such as an edge device 890, which can beconsidered similar to the sensor 540 of FIG. 5, sensor 460 of FIG. 4,and sensor 102 of FIG. 1.

In another embodiment, key handling information 840, exemplarilyproviding security and authorized access that is exemplarily controlledby the application deployment system 810, for each, or individual,target components of the divided system can be generated at theapplication deployment system 810 and applied to downstream components,such as cloud server 870, similar to server 590 of FIG. 5, server 480 ofFIG. 4, and server 106 of FIG. 1. Additionally, key handling information840 for each, or individual, target components of the divided system canbe generated at the application deployment system 810 and applied todownstream components, such as gateway 880, which can be conceptuallysimilar to gateway 540 of FIG. 5, gateway 470 of FIG. 4, and gateway 104of FIG. 1. Likewise, key handling information 840 for each, orindividual, target components of the divided system can be generated atthe application deployment system 810 and applied to downstreamcomponents, such as an edge device 890, which is comparable to thesensor 540 of FIG. 5, sensor 460 of FIG. 4, and sensor 102 of FIG. 1.

In additional embodiments, encryption codes 850, exemplarily ensuringthat the update and access to the various discrete components of theheterogenous system is exemplarily controlled by the applicationdeployment system 810, for each, or individual, target components of thedivided system can be generated at the application deployment system 810and applied to downstream components, such as cloud server 870, similarto server 590 of FIG. 5, server 480 of FIG. 4, and server 106 of FIG. 1.Similarly, the key handling information 840 can be used to gain, forexample, access to the encryption codes 850 to access the varioussoftware updates 820, serialization, and de-serialization codes 830,exemplarily being received via the transmission or transport step 860,described below. Additionally, encryption codes 850, for each, orindividual, target components of the divided system can be generated atthe application deployment system 810 and applied to downstreamcomponents, such as gateway 880, comparable to gateway 540 of FIG. 5,gateway 470 of FIG. 4, and gateway 104 of FIG. 1. Likewise, encryptioncodes 850, for each, or individual, target components of the dividedsystem can be generated at the application deployment system 810 andapplied to downstream components, such as an edge device 890, which canbe considered like the sensor 540 of FIG. 5, sensor 460 of FIG. 4, andsensor 102 of FIG. 1.

In another embodiment, the application deployment system 810 performs atransmission or transport step 860 that is exemplarily controlled by theapplication deployment system 810 to provide the various serializationcodes, programming, and other instructions for each, or individual,target components of the divided system can be generated at theapplication deployment system 810 and applied to downstream components,such as cloud server 870, similar to server 590 of FIG. 5, server 480 ofFIG. 4, and server 106 of FIG. 1. Additionally, the transport step 860communicates with each, or individual, target components of the dividedsystem from the application deployment system 810 and applied todownstream components, such as gateway 880, similar to gateway 540 ofFIG. 5, gateway 470 of FIG. 4, and gateway 104 of FIG. 1. Likewise, thetransport step 860 communicates with each, or individual, targetcomponents of the divided system from the application deployment system810 and applied to downstream components, such as an edge device 890,which can be considered similar to the sensor 540 of FIG. 5, sensor 460of FIG. 4, and sensor 102 of FIG. 1.

Exemplarily, in system 800, the heterogenous system 400 of FIG. 4, forexample, can be analyzed and divided as exemplarily illustrated inmethod 300 of FIG. 3. The application deployment system 810 can thenupdate the downstream components, such as edge device 870, gateway 880,and server 890 with updated code, division of work, and the addition orremoval of components to the heterogenous system. In some embodiments,any number of servers 890 may be updated while a potentially unlimitedgateway devices 880 and downstream components, such as a large-scalesensing operation comprising potentially unlimited downstream sensorsand other components, such as the edge device 870, can be updated andcontrolled by the application deployment system 810.

FIG. 9 is an exemplary illustration of an embodiment the presentinvention deploying code to downstream elements of system 900 inaccordance with method 300 of FIG. 3. System 900 exemplary illustrates aheterogenous system including a sensor device 910, a gateway 920, andserver 930. These three elements exemplarily perform separate tasks togenerate an output illustrated in element 940. In accordance with method300 of FIG. 3 and utilizing, for example, system 800 of FIG. 8 where anapplication deployment system 810 can exemplarily update the operationof system 900. In this example, the heterogenous system has beenanalyzed in accordance with method 300 to determine the individualcomponents. Referring to FIG. 8, software updates 820 have beendeveloped and compiled to be distributed to the updated system 950 ofFIG. 9. In this example, the software updates are distributed to sensordevice 910, gateway 920, and server 930 to perform updated operationsresulting in modified output 960 from updated system 950.

In the example of updating system 900, the previous programming can berepresented as shown in table 1 below where the sensor device 910 waspreviously programmed to perform a timing task and to then output thatvalue. The gateway 920 adds the value of 20 to that value while theserver 930 adds a value of 300 to that value.

TABLE 1 tag(′sensor) {  Sampler(2 seconds) −>   triggered {    new {    private var i = 0     def apply ( ) : R[Int] = { i += 1; i } % 10   }   } } −> tag(′gateway) {  ( x: R[Int] => 20 + x ) } −> tag(′server){  ( x: R[Int] => 300 + x ) } −> tag(′output) {  sink ( x: R[Int] =>println(x)} }

Next, in the example of reprogramming the elements of system 900 toprovide the updated system 950, table 2 illustrates the newly addedcode. The newly added code instructs the sensor device 910 to perform atiming task, multiply that value by 2 and to then output that value. Thegateway 920 is now instructed to add the value of 30 to that value whilethe server 930 now adds a value of 500 to that value. This allowsexemplary embodiments of the invention to provide changes to system 900that ultimately changes the output 940 of a series of numbers of 321through 329 to the modified output 960 of a series of values starting at530 and stepping by a value of two to 538.

TABLE 2 tag (′sensor) {  Sampler(1 seconds) −>   triggered {    new {    private var i = 0     def apply ( ) : R[Int] = { i += 2; i } % 10   }   } } −> tag(′gateway) {  ( x: R[Int] => 30 + x ) } −> tag(′server){  ( x: R[Int] => 500 + x ) } −> tag(′output) {  sink ( x: R[Int] =>println(x) } }

FIG. 10 is another exemplary illustration of an embodiment the presentinvention deploying code to downstream elements of system 1010 inaccordance with method 300 of FIG. 3. In this example, system 1010 is aheterogenous system that is composed of an embedded node 1020 and clouddatabase 1030. Exemplarily, the embedded node 1020 performs a sensingand recording function while the cloud database 1030 performs ananalysis and archive function. After performing the elements of method300 of FIG. 3 and being distributed via the application deploymentsystem 810 of FIG. 8, system 1010 has been updated into updated system1040. In the updated system 1040, a fog gateway 1050 has been added tothe heterogenous system of system 1010. In updated system 1040, the foggateway 1050 has been assigned the recording and analysis tasks whilethe embedded node 1020 has been assigned the sensing functions and thecloud database 1030 retains its archive function. In other embodiments,additional elements can be added or removed from system 1010 in anycombination of newly added functions and devices.

Hardware Architecture

Generally, the techniques disclosed herein may be implemented onhardware or a combination of software and hardware. For example, theymay be implemented in an operating system kernel, in a separate userprocess, in a library package bound into network applications, on aspecially constructed machine, on an application-specific integratedcircuit (ASIC), or on a network interface card.

Software/hardware hybrid implementations of at least some of theembodiments disclosed herein may be implemented on a programmablenetwork-resident machine (which should be understood to includeintermittently connected network-aware machines) selectively activatedor reconfigured by a computer program stored in memory. Such networkdevices may have multiple network interfaces that may be configured ordesigned to utilize different types of network communication protocols.A general architecture for some of these machines may be describedherein in order to illustrate one or more exemplary means by which agiven unit of functionality may be implemented. According to specificembodiments, at least some of the features or functionalities of thevarious embodiments disclosed herein may be implemented on one or moregeneral-purpose computers associated with one or more networks, such asfor example an end-user computer system, a client computer, a networkserver or other server system, a mobile computing device (e.g., tabletcomputing device, mobile phone, smartphone, laptop, or other appropriatecomputing device), a consumer electronic device, a music player, or anyother suitable electronic device, router, switch, or other suitabledevice, or any combination thereof. In at least some embodiments, atleast some of the features or functionalities of the various embodimentsdisclosed herein may be implemented in one or more virtualized computingenvironments (e.g., network computing clouds, virtual machines hosted onone or more physical computing machines, or other appropriate virtualenvironments).

Referring now to FIG. 11, there is shown a block diagram depicting anexemplary computing device 10 suitable for implementing at least aportion of the features or functionalities disclosed herein. Computingdevice 10 may be, for example, any one of the computing machines listedin the previous paragraph, or indeed any other electronic device capableof executing software- or hardware-based instructions according to oneor more programs stored in memory. Computing device 10 may be configuredto communicate with a plurality of other computing devices, such asclients or servers, over communications networks such as a wide areanetwork a metropolitan area network, a local area network, a wirelessnetwork, the Internet, or any other network, using known protocols forsuch communication, whether wireless or wired.

In one aspect, computing device 10 includes one or more centralprocessing units (CPU) 12, one or more interfaces 15, and one or morebusses 14 (such as a peripheral component interconnect (PCI) bus). Whenacting under the control of appropriate software or firmware, CPU 12 maybe responsible for implementing specific functions associated with thefunctions of a specifically configured computing device or machine. Forexample, in at least one aspect, a computing device 10 may be configuredor designed to function as a server system utilizing CPU 12, localmemory 11 and/or remote memory 16, and interface(s) 15. In at least oneaspect, CPU 12 may be caused to perform one or more of the differenttypes of functions and/or operations under the control of softwaremodules or components, which for example, may include an operatingsystem and any appropriate applications software, drivers, and the like.

CPU 12 may include one or more processors 13 such as, for example, aprocessor from one of the Intel, ARM, Qualcomm, and AMD families ofmicroprocessors. In some embodiments, processors 13 may includespecially designed hardware such as application-specific integratedcircuits (ASICs), electrically erasable programmable read-only memories(EEPROMs), field-programmable gate arrays (FPGAs), and so forth, forcontrolling operations of computing device 10. In a particular aspect, alocal memory 11 (such as non-volatile random-access memory (RAM) and/orread-only memory (ROM), including for example one or more levels ofcached memory) may also form part of CPU 12. However, there are manydifferent ways in which memory may be coupled to system 10. Memory 11may be used for a variety of purposes such as, for example, cachingand/or storing data, programming instructions, and the like. It shouldbe further appreciated that CPU 12 may be one of a variety ofsystem-on-a-chip (SOC) type hardware that may include additionalhardware such as memory or graphics processing chips, such as a QUALCOMMSNAPDRAGON™ or SAMSUNG EXYNOS™ CPU as are becoming increasingly commonin the art, such as for use in mobile devices or integrated devices.

As used herein, the term “processor” is not limited merely to thoseintegrated circuits referred to in the art as a processor, a mobileprocessor, or a microprocessor, but broadly refers to a microcontroller,a microcomputer, a programmable logic controller, anapplication-specific integrated circuit, and any other programmablecircuit.

In one aspect, interfaces 15 are provided as network interface cards(NICs). Generally, NICs control the sending and receiving of datapackets over a computer network; other types of interfaces 15 may forexample support other peripherals used with computing device 10. Amongthe interfaces that may be provided are Ethernet interfaces, frame relayinterfaces, cable interfaces, DSL interfaces, token ring interfaces,graphics interfaces, and the like. In addition, various types ofinterfaces may be provided such as, for example, universal serial bus(USB), Serial, Ethernet, FIREWIRE™, THUNDERBOLT™, PCI, parallel, radiofrequency (RF), BLUETOOTH™, near-field communications (e.g., usingnear-field magnetics), 802.11 (WiFi), frame relay, TCP/IP, ISDN, fastEthernet interfaces, Gigabit Ethernet interfaces, Serial ATA (SATA) orexternal SATA (ESATA) interfaces, high-definition multimedia interface(HDMI), digital visual interface (DVI), analog or digital audiointerfaces, asynchronous transfer mode (ATM) interfaces, high-speedserial interface (HSSI) interfaces, Point of Sale (POS) interfaces,fiber data distributed interfaces (FDDIs), and the like. Generally, suchinterfaces 15 may include physical ports appropriate for communicationwith appropriate media. In some cases, they may also include anindependent processor (such as a dedicated audio or video processor, asis common in the art for high-fidelity A/V hardware interfaces) and, insome instances, volatile and/or non-volatile memory (e.g., RAM).

Although the system shown in FIG. 11 illustrates one specificarchitecture for a computing device 10 for implementing one or more ofthe embodiments described herein, it is by no means the only devicearchitecture on which at least a portion of the features and techniquesdescribed herein may be implemented. For example, architectures havingone or any number of processors 13 may be used, and such processors 13may be present in a single device or distributed among any number ofdevices. In one aspect, single processor 13 handles communications aswell as routing computations, while in other embodiments a separatededicated communications processor may be provided. In variousembodiments, different types of features or functionalities may beimplemented in a system according to the aspect that includes a clientdevice (such as a tablet device or smartphone running client software)and server systems (such as a server system described in more detailbelow).

Regardless of network device configuration, the system of an aspect mayemploy one or more memories or memory modules (such as, for example,remote memory block 16 and local memory 11) configured to store data,program instructions for the general-purpose network operations, orother information relating to the functionality of the embodimentsdescribed herein (or any combinations of the above). Programinstructions may control execution of or comprise an operating systemand/or one or more applications, for example. Memory 16 or memories 11,16 may also be configured to store data structures, configuration data,encryption data, historical system operations information, or any otherspecific or generic non-program information described herein.

Because such information and program instructions may be employed toimplement one or more systems or methods described herein, at least somenetwork device embodiments may include nontransitory machine-readablestorage media, which, for example, may be configured or designed tostore program instructions, state information, and the like forperforming various operations described herein. Examples of suchnontransitory machine-readable storage media include, but are notlimited to, magnetic media such as hard disks, floppy disks, andmagnetic tape; optical media such as CD-ROM disks; magneto-optical mediasuch as optical disks, and hardware devices that are speciallyconfigured to store and perform program instructions, such as read-onlymemory devices (ROM), flash memory (as is common in mobile devices andintegrated systems), solid state drives (SSD) and “hybrid SSD” storagedrives that may combine physical components of solid state and hard diskdrives in a single hardware device (as are becoming increasingly commonin the art with regard to personal computers), memristor memory, randomaccess memory (RAM), and the like. It should be appreciated that suchstorage means may be integral and non-removable (such as RAM hardwaremodules that may be soldered onto a motherboard or otherwise integratedinto an electronic device), or they may be removable such as swappableflash memory modules (such as “thumb drives” or other removable mediadesigned for rapidly exchanging physical storage devices),“hot-swappable” hard disk drives or solid state drives, removableoptical storage discs, or other such removable media, and that suchintegral and removable storage media may be utilized interchangeably.Examples of program instructions include both object code, such as maybe produced by a compiler, machine code, such as may be produced by anassembler or a linker, byte code, such as may be generated by forexample a JAVA™ compiler and may be executed using a Java virtualmachine or equivalent, or files containing higher level code that may beexecuted by the computer using an interpreter (for example, scriptswritten in Python, Perl, Ruby, Groovy, or any other scripting language).

In some embodiments, systems may be implemented on a standalonecomputing system. Referring now to FIG. 12, there is shown a blockdiagram depicting a typical exemplary architecture of one or moreembodiments or components thereof on a standalone computing system.Computing device 20 includes processors 21 that may run software thatcarry out one or more functions or applications of embodiments, such asfor example a client application 24. Processors 21 may carry outcomputing instructions under control of an operating system 22 such as,for example, a version of MICROSOFT WINDOWS™ operating system, APPLEmacOS™ or iOS™ operating systems, some variety of the Linux operatingsystem, ANDROID™ operating system, or the like. In many cases, one ormore shared services 23 may be operable in system 20, and may be usefulfor providing common services to client applications 24. Services 23 mayfor example be WINDOWS™ services, user-space common services in a Linuxenvironment, or any other type of common service architecture used withoperating system 21. Input devices 28 may be of any type suitable forreceiving user input, including for example a keyboard, touchscreen,microphone (for example, for voice input), mouse, touchpad, trackball,or any combination thereof. Output devices 27 may be of any typesuitable for providing output to one or more users, whether remote orlocal to system 20, and may include for example one or more screens forvisual output, speakers, printers, or any combination thereof. Memory 25may be random-access memory having any structure and architecture knownin the art, for use by processors 21, for example to run software.Storage devices 26 may be any magnetic, optical, mechanical, memristor,or electrical storage device for storage of data in digital form (suchas those described above, referring to FIG. 5). Examples of storagedevices 26 include flash memory, magnetic hard drive, CD-ROM, and/or thelike.

In some embodiments, systems may be implemented on a distributedcomputing network, such as one having any number of clients and/orservers. Referring now to FIG. 13, there is shown a block diagramdepicting an exemplary architecture 30 for implementing at least aportion of a system according to one aspect on a distributed computingnetwork. According to the aspect, any number of clients 33 may beprovided. Each client 33 may run software for implementing client-sideportions of a system; clients may comprise a system 20 such as thatillustrated in FIG. 6. In addition, any number of servers 32 may beprovided for handling requests received from one or more clients 33.Clients 33 and servers 32 may communicate with one another via one ormore electronic networks 31, which may be in various embodiments any ofthe Internet, a wide area network, a mobile telephony network (such asCDMA or GSM cellular networks), a wireless network (such as WiFi, WiMAX,LTE, and so forth), or a local area network (or indeed any networktopology known in the art; the aspect does not prefer any one networktopology over any other). Networks 31 may be implemented using any knownnetwork protocols, including for example wired and/or wirelessprotocols.

In addition, in some embodiments, servers 32 may call external services37 when needed to obtain additional information, or to refer toadditional data concerning a particular call. Communications withexternal services 37 may take place, for example, via one or morenetworks 31. In various embodiments, external services 37 may compriseweb-enabled services or functionality related to or installed on thehardware device itself. For example, in one aspect where clientapplications 24 are implemented on a smartphone or other electronicdevice, client applications 24 may obtain information stored in a serversystem 32 in the cloud or on an external service 37 deployed on one ormore of a particular enterprise's or user's premises.

In some embodiments, clients 33 or servers 32 (or both) may make use ofone or more specialized services or appliances that may be deployedlocally or remotely across one or more networks 31. For example, one ormore databases 34 may be used or referred to by one or more embodiments.It should be understood by one having ordinary skill in the art thatdatabases 34 may be arranged in a wide variety of architectures andusing a wide variety of data access and manipulation means. For example,in various embodiments one or more databases 34 may comprise arelational database system using a structured query language (SQL),while others may comprise an alternative data storage technology such asthose referred to in the art as “NoSQL” (for example, HADOOP CASSANDRA™,GOOGLE BIGTABLE™, and so forth). In some embodiments, variant databasearchitectures such as column-oriented databases, in-memory databases,clustered databases, distributed databases, or even flat file datarepositories may be used according to the aspect. It will be appreciatedby one having ordinary skill in the art that any combination of known orfuture database technologies may be used as appropriate, unless aspecific database technology or a specific arrangement of components isspecified for a particular aspect described herein. Moreover, it shouldbe appreciated that the term “database” as used herein may refer to aphysical database machine, a cluster of machines acting as a singledatabase system, or a logical database within an overall databasemanagement system. Unless a specific meaning is specified for a givenuse of the term “database”, it should be construed to mean any of thesesenses of the word, all of which are understood as a plain meaning ofthe term “database” by those having ordinary skill in the art.

Similarly, some embodiments may make use of one or more security systems36 and configuration systems 35. Security and configuration managementare common information technology (IT) and web functions, and someamount of each are generally associated with any IT or web systems. Itshould be understood by one having ordinary skill in the art that anyconfiguration or security subsystems known in the art now or in thefuture may be used in conjunction with embodiments without limitation,unless a specific security 36 or configuration system 35 or approach isspecifically required by the description of any specific aspect.

FIG. 14 shows an exemplary overview of a computer system 40 as may beused in any of the various locations throughout the system. It isexemplary of any computer that may execute code to process data. Variousmodifications and changes may be made to computer system 40 withoutdeparting from the broader scope of the system and method disclosedherein. Central processor unit (CPU) 41 is connected to bus 42, to whichbus is also connected memory 43, nonvolatile memory 44, display 47,input/output (I/O) unit 48, and network interface card (NIC) 53. I/Ounit 48 may, typically, be connected to keyboard 49, pointing device 50,hard disk 52, and real-time clock 51. NIC 53 connects to network 54,which may be the Internet or a local network, which local network may ormay not have connections to the Internet. Also shown as part of system40 is power supply unit 45 connected, in this example, to a mainalternating current (AC) supply 46. Not shown are batteries that couldbe present, and many other devices and modifications that are well knownbut are not applicable to the specific novel functions of the currentsystem and method disclosed herein. It should be appreciated that someor all components illustrated may be combined, such as in variousintegrated applications, for example Qualcomm or Samsungsystem-on-a-chip (SOC) devices, or whenever it may be appropriate tocombine multiple capabilities or functions into a single hardware device(for instance, in mobile devices such as smartphones, video gameconsoles, in-vehicle computer systems such as navigation or multimediasystems in automobiles, or other integrated hardware devices).

In various embodiments, functionality for implementing systems ormethods of various embodiments may be distributed among any number ofclient and/or server components. For example, various software modulesmay be implemented for performing various functions in connection withthe system of any particular aspect, and such modules may be variouslyimplemented to run on server and/or client components.

The skilled person will be aware of a range of possible modifications ofthe various embodiments described above. Accordingly, the presentinvention is defined by the claims and their equivalents.

ADDITIONAL CONSIDERATIONS

As used herein any reference to “one embodiment” or “an embodiment”means that a particular element, feature, structure, or characteristicdescribed in connection with the embodiment is included in at least oneembodiment. The appearances of the phrase “in one embodiment” in variousplaces in the specification are not necessarily all referring to thesame embodiment.

Some embodiments may be described using the expression “coupled” and“connected” along with their derivatives. For example, some embodimentsmay be described using the term “coupled” to indicate that two or moreelements are in direct physical or electrical contact. The term“coupled,” however, may also mean that two or more elements are not indirect contact with each other, but yet still co-operate or interactwith each other. The embodiments are not limited in this context.

As used herein, the terms “comprises,” “comprising,” “includes,”“including,” “has,” “having” or any other variation thereof, areintended to cover a non-exclusive inclusion. For example, a process,method, article, or apparatus that comprises a list of elements is notnecessarily limited to only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Further, unless expressly stated to the contrary,“or” refers to an inclusive or and not to an exclusive or. For example,a condition A or B is satisfied by any one of the following: A is true(or present) and Bis false (or not present), A is false (or not present)and Bis true (or present), and both A and B are true (or present).

In addition, use of the “a” or “an” are employed to describe elementsand components of the embodiments herein. This is done merely forconvenience and to give a general sense of the invention. Thisdescription should be read to include one or at least one and thesingular also includes the plural unless it is obvious that it is meantotherwise.

Upon reading this disclosure, those of skill in the art will appreciatestill additional alternative structural and functional designs for asystem and a process for creating an interactive message through thedisclosed principles herein. Thus, while particular embodiments andapplications have been illustrated and described, it is to be understoodthat the disclosed embodiments are not limited to the preciseconstruction and components disclosed herein. Various apparentmodifications, changes and variations may be made in the arrangement,operation and details of the method and apparatus disclosed hereinwithout departing from the spirit and scope defined in the appendedclaims.

What is claimed is:
 1. A method, the method comprising: identifying, bya processing system comprising a processor, an individual component fromamong a plurality of components in a target system as an identifiedcomponent of a plurality of identified components; mapping, by theprocessing system, each one of the identified components to respectiveones of a target hardware node; generating, by the processing system,intermediate code for each respective one of the target hardware nodes;generating, by the processing system, serialization code for eachrespective communication interface between the target hardware nodes;transmitting, by the processing system, the respective intermediatecodes to each one of the target hardware nodes; and transmitting, by theprocessing system, respective serialization codes to each communicationinterface of the target hardware nodes.
 2. The method of claim 1,wherein the identifying comprises identifying message-passing boundariesbetween code paths in the target system.
 3. The method of claim 1,wherein the identifying comprises identifying data dependencies betweencode paths in the target system.
 4. The method of claim 1, wherein thegenerating the intermediate code comprises accessing a library togenerate specialized code for the respective target hardware nodes. 5.The method of claim 4, wherein the library comprises a generic library,an architecture-optimized library, and a part-specific library.
 6. Themethod of claim 1, wherein the generating the serialization codecomprises: detecting a message type being provided between therespective communication interface; and determining a serializationstrategy for the message type according to security requirements for therespective communication interface and a channel configuration of therespective communication interface.
 7. The method of claim 1, whereinthe method further comprises transforming the respective intermediatecodes into a format of the respective target hardware node.
 8. Acomputer program product comprising a non-transitory computer readablestorage medium having instructions encoded thereon that, when executedby a processor, cause the processor to: consume an applicationspecification associated with a plurality of devices provided in anetwork environment as a consumed application specification; identifyindependent components in the network by identifying message-passingboundaries between code paths as identified independent components; mapthe consumed application specification to the identified independentcomponents by leveraging one or more code libraries; encode one moreobjects of the consumed application specification for a targetcommunication channel by detecting message types that may traverse eachchannel from one target node to another; and transform the consumedapplication specification into a format suitable for a target node. 9.The computer program of claim 8, wherein the encoding of the one of moreobjects further comprises encoding the consumed applicationspecification according to a determined security need for thecommunication channel.
 10. The computer program of claim 8, wherein thecode library comprises one of a generic library, anarchitecture-optimized library, and a part-specific library.
 11. Asystem, comprising: a processing system including a processor; and amemory, coupled to the processing system, that stores executableinstructions and that, when executed by the processing system,facilitate performance of operations, comprising: identifying anindividual component from among a plurality of components in a targetsystem as an identified component of a plurality of identifiedcomponents; mapping each one of the identified components to respectiveones of a target hardware node; generating serialization code for eachrespective communication interface between the target hardware nodes;and transmitting, by the processing system, respective serializationcodes to each communication interface of the target hardware nodes. 12.The system of claim 11, wherein the identifying comprises identifyingmessage-passing boundaries between code paths in the target system. 13.The system of claim 11, wherein the identifying comprises identifyingdata dependencies between code paths in the target system.
 14. Thesystem of claim 11, wherein the generating the serialization codecomprises detecting a message type being provided between the respectivecommunication interface.
 15. The system of claim 14, wherein thegenerating the serialization code further comprises determining aserialization strategy for the message type according to securityrequirements for the respective communication interface and a channelconfiguration of the respective communication interface.
 16. The systemof claim 11, wherein the operations further comprise generatingintermediate code for each respective one of the target hardware nodes.17. The system of claim 16, wherein the operations further comprisetransforming the respective intermediate codes into a format of therespective target hardware node.
 18. The system of claim 16, wherein theoperations further comprise transmitting the respective intermediatecodes to each one of the target hardware nodes.
 19. The system of claim16, wherein the generating the intermediate code comprises accessing alibrary to generate specialized code for the respective target hardwarenodes.
 20. The system of claim 19, wherein the library comprises ageneric library, an architecture-optimized library, and a part-specificlibrary.